Subject: First response to Randy Presuhn's APPN MIB comments

From: "R.E. (Robert) Moore (254-4436)" <[email-masked]>
Date: Tue, 20 Aug 96 14:41:59 EDT

I've made a pass through Randy's comments on the APPN MIB, and inserted
a "BobM>" response to each.  These are not necessarily how we'll word our
responses to Randy--they're just for the WG / SIG for now.

I'll start editing the APPN MIB, to make the changes that are (or at
least should be!) non-controversial.  Meanwhile, if anyone has something
to add on any of these 69 points, please speak up.

Thanks,
Bob Moore, IBM Network Management Architecture
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Date: Thu, 25 Jul 1996 13:59:45 -0700
From: Randy Presuhn <[email-masked]>
To: [email-masked]
Subject: APPN MIB Review
Cc: [email-masked], [email-masked], [email-masked]
Mime-Version: 1.0
Content-Type: text/plain; charset=X-roman8
Content-Transfer-Encoding: 7bit

Hi Bill -

Attached are my initial comments on <draft-ietf-snanau-appnmib-01.txt>
The only problem detected by the mib compilers I tried was in the use
of potentially negative numbers of indexes.  The remaining problems
are more subtle - semantic / stylistic issues or requirements imposed
by RFC 1902 that cannot be evaluated by a compiler.

Feel free to give me a call if you have any questions.

 -----------------------------------------------------------------------------
 Randy Presuhn                 PEER Networks, a division of BMC Software, Inc.
 Voice: +1 408 556-0720        1190 Saratoga Avenue, Suite 130
 Fax:   +1 408 556-0735        San Jose, California 95129-3433
 Email: [email-masked]  USA
 -----------------------------------------------------------------------------
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

             These  are  my  initial  comments developed in reviewing the
        Definitions of Managed Objects for  APPN  in  <draft-ietf-snanau-
        appnmib-01.txt>.  Most comments fall into these categories:

             1    cases  where  Integer32  was  used  when Unsigned32 was
                  probably intended

             2    identification of discontinuity indicators for counters

             3    clarification of description texts

             4    conventions  for  strings,  especially hex statuses and
                  names

             In most cases, I would expect the resolution of an  item  to
        be  handled  consistently for all relevant definitions identified
        in that item.  Some of these issues, such as the use  of  textual
        conventions,  are a matter of stylistic preferences, though argu-
        ments can be made in terms of maintainability and ease of use.

        Item:      1
        Page:      -
        Clause:    -
        Qualifier: general
        Rationale: The definitions of the  tables  appnPortTable,  appnL-
                   sTable, appnLsStatusTable, appnVrnTable, appnNnTopolo-
                   gyFRTable, appnNnTgTopologyFRTable,  appnLocalTgTable,
                   appnLocalEnTgTable,   appnDirTable,  appnCosModeTable,
                   appnCosNameTable,    appnCosNodeRowTable,    appnCosT-
                   gRowTable,  appnIsInTable,  and  appnIsRtpTable do not
                   describe the conditions under which entries are  added
                   or deleted.  The MIB definitions do not provide a low-
                   overhead mechanism for detecting changes to tables.

        Proposal:  Make the decision to do this a conscious one.

BobM> We'll need to respond to Randy, saying that the decision was a
BobM> conscious one, and that while it's unusual, we *do* have a low-
BobM> overhead way of detecting changes to the FR tables.

        Item:      2
        Page:      -
        Clause:    -
        Qualifier: general
        Rationale: The way the definitions are currently written make  it
                   impossible  for  a future version of this MIB to allow
                   management operations  to  create/delete  table  rows,
                   modify configuration parameters, and so on.

        Proposal:  Make  the  decision  to  do  this a conscious one.  If
                   there is a realistic possibility that management  con-
                   trol will be needed, it would make sense to modify the
                   relevant MAX-ACCESS clauses from "read-only" to "read-
                   write"  or "read-create", and to use the MIN-ACCESS in
                   the MODULE-COMPLIANCE section to set  the  "read-only"
                   expectation.

BobM> We'll need to respond to Randy, saying that the decision was a
BobM> conscious one.

        Item:      3
        Page:      2
        Clause:    4
        Qualifier: editorial
        Rationale: This document is presumably more than a proposal.

        Proposal:  Replace  "the proposed" with "a" in the first sentence
                   of the first paragraph.

BobM> OK; BobC to fix.

        Item:      4
        Page:      2
        Clause:    4
        Qualifier: editorial
        Rationale: Consistency of reference style.

        Proposal:  Replace "(RFC1666 [8])" with "[8]" in the first  para-
                   graph.

BobM> OK; BobC to fix.

        Item:      5
        Page:      2
        Clause:    4
        Qualifier: editorial
        Rationale: English usage.

        Proposal:  Replace  "is  comprised  of"  with  "comprises" in the
                   first sentence of the second paragraph.

BobM> OK; BobC to fix.

        Item:      6
        Page:      3
        Clause:    4
        Qualifier: editorial
        Rationale: Typo.

        Proposal:  Replace "LLCMIB" with "LLC MIB" in the first paragraph
                   on page 3.

BobM> OK; BobC to fix.

        Item:      7
        Page:      3
        Clause:    4
        Qualifier: minor
        Rationale: It  is  not  entirely  clear in the MIB module exactly
                   which  variables  are  subject  to   the   constraints
                   described  in  fifth paragraph on SNA name representa-
                   tion.

        Proposal:  Include this text as part of a textual convention, and
                   use  that  textual  convention  for  the SYNTAX of the
                   variables to  which  these  constraints  apply.   This
                   would   appear  to  affect  appnPortName,  appnLsName,
                   appnLsPortName, appnLocalTgDest,  appnLocalTgPortName,
                   appnLocalEnTgOrigin, appnLocalEnTgDest, appnDirLuName,
                   appnDirNnServerName, appnDirLuOwnerName, appnCosTgRow-
                   Name,  appnIsInPriLuName,  and  appnIsInSecLuName.  It
                   would be advisable to examine all DisplayString usages
                   to  determine  which  ones  are  subject to these con-
                   straints.

BobM> OK in principle.  I'll update the MIB module with several TCs,
BobM> for the different varieties of names present in the MIB.  After
BobM> I've done this, BobC can determine whether the front matter needs
BobM> to be changed as well.

        Item:      8
        Page:      4
        Clause:    4
        Qualifier: Major
        Rationale: The example given of a GET-NEXT request using an index
                   of  "M        " assumes that no character with a value
                   less than 32  (space)  may  appear  in  one  of  these
                   indexes.  This constraint is not stated.

        Proposal:  Either add text identifying the set of characters per-
                   mitted, or correct the example to use the probe  value
                   of  8.77  (no additional subidentifiers) to obtain the
                   element indexed by first 8-character string  beginning
                   with "M".

BobM> I'll add character set descriptions to the textual conventions.
BobM> BobC will re-work this example.

        Item:      9
        Page:      4
        Clause:    4
        Qualifier: editorial
        Rationale: The two occurrances of "M" in the paragraph at the top
                   of the page should be in quotes.

        Proposal:  Add the missing quotes.

BobM> OK; BobC to fix.

        Item:      10
        Page:      -
        Clause:    -
        Qualifier: editorial
        Rationale: Several abbreviations are not  expanded  before  being
                   used,  although  in  some  cases  an expansion appears
                   later in the text.  Though  most  of  these  would  be
                   fairly  obvious  to  the SNA-aware, the lack of expan-
                   sions is inconsistent  with  the  expansion  of  other
                   basic SNA-isms in this document.

                   ABM,  ACTPU, ANR, APPC, CS, CV22, DLUR, FMD, HPR, LLC,
                   LU, MAC, MS, MU, NAU, NCE, NRM, PIU,  RSCV,  RTP,  RU,
                   SAP, SDLC, SNA, SSCP, TDU, XID.

        Proposal:  Add the missing definitions as needed.

BobM> I agree with the comment, but I'm not sure how/where to put the
BobM> expansions for these acronyms.  Any suggestions?

        Item:      11
        Page:      10
        Clause:    5
        Qualifier: minor
        Rationale: Is  "{  experimental  1000 }" the correct registration
                   for this MIB?

        Proposal:  Update with the official registration.

BobM> Bill Kwan is working on this.  He should have a fix to propose in
BobM> a few days.

        Item:      12
        Page:      10
        Clause:    5
        Qualifier: minor
        Rationale: The description of SnaSenseData does not  specify  the
                   set  of  characters permitted.  In particular, if hex-
                   adecimal numbers show up here, are a-f upper or  lower
                   case?

        Proposal:  Identify the permitted characters in these strings and
                   the mapping from how the information is represented in
                   SNA-land.

BobM> OK; BobM to fix.

        Item:      13
        Page:      11+
        Clause:    5
        Qualifier: minor
        Rationale: In   the   definitions   of   appnNodeCpName,   appnN-
                   odeEnNnServer,  appnLsAdjCpName,   appnLsStatusCpName,
                   appnNnNodeFRName,   appnNnTgFROwner,  appnDirNnServer-
                   Name, appnDirLuOwnerName, appnIsInFqCpName,  and  app-
                   nIsInSsAdjCpName,  the  notation describing the format
                   of network names is unclear  due  to  the  unfortunate
                   puctuation of the description clause.

        Proposal:  Define  a  textual convention for use in these defini-
                   tions, and make it clear that  only  the  dot  between
                   NetId and CpName belongs to the format.

BobM> OK; BobM to fix.

        Item:      14
        Page:      11+
        Clause:    5
        Qualifier: minor
        Rationale: In the definitions of appnNodeId, appnLsPartnerNodeId,
                   and appnLsStatusPartnerId, the  description  does  not
                   make it clear what characters are used in the hexadec-
                   imal representation, e.g., uppercase or lowercase  for
                   A-F,  whether  leading zeroes can be mapped to spaces,
                   and so on.

        Proposal:  Define a textual convention  for  hexadecimal  strings
                   like  these, clearly defining whether zero-suppression
                   is allowed and what characters are used for what  dig-
                   its.

BobM> OK; BobM to fix.

        Item:      15
        Page:      11+
        Clause:    5
        Qualifier: minor
        Rationale: In  the  definitions  of  appnNodeType, appnNodeParal-
                   lelTg, appnNodeAdaptiveBindPacing, appnNodeHprSupport,
                   appnNodeNnCentralDirectory,       appnNodeNnTreeCache,
                   appnNodeNnIsr, appnNodeNnPeriBorderSup,  appnNodeNnIn-
                   terchangeSup,  appnNodeNnExteBorderSup,  appnNodeNnIs-
                   rDepleted,   appnNodeNnQuiescing,   appnNodeNnGateway,
                   appnNodeEnModeCosMap,  appnNodeEnLuSearch, appnPortOp-
                   erState, appnPortPortType, appnPortSIMRIM, appnPortNe-
                   gotLs,   appnPortDynamicLinkSupport,  appnLsOperState,
                   appnLsAdjNodeType,  appnLsLimResource,  appnLsActOnDe-
                   mand,    appnLsMigration,    appnLsCpCpSessionSupport,
                   appnLsErrRecoSup, appnLsStatusRetry, appnNnNodeFRType,
                   appnNnNodeFRCongested,        appnNnNodeFRIsrDepleted,
                   appnNnNodeFRQuiescing,  appnNnNodeFRGateway,  appnNnN-
                   odeFRCentralDirectory,  appnNnNodeFRIsr, appnNnNodeFR-
                   GarbageCollect, appnNnNodeFRHprSupport,  appnNnNodeFR-
                   PeriBorderSup, appnNnNodeFRInterchangeSup, appnNnNode-
                   FRExteBorderSup, appnNnTgFRDestVirtual,  appnNnTgFROp-
                   erational, appnNnTgFRQuiescing, appnNnTgFRCpCpSession,
                   appnNnTgFRSecurity, appnNnTgFRGarbageCollect, appnNnT-
                   gFRHprSup, appnNnTgFRDestHprTrans, appnNnTgFRTypeIndi-
                   cator, appnNnTgFRIntersubnet,  appnLocalTgDestVirtual,
                   appnLocalTgQuiescing,  appnLocalTgOperational, appnLo-
                   calTgCpCpSession, appnLocalTgHprSup, appnLocalTgInter-
                   subnet,                      appnLocalEnTgDestVirtual,
                   appnLocalEnTgOperational,    appnLocalEnTgCpCpSession,
                   appnCosTransPriority,  and  appnIsInTransPriority, the
                   relationship between the labels provided in  the  list
                   of possible values and the elements of the description
                   clause is not clear.

        Proposal:  In the description  clause,  explicitly  identify  the
                   label corresponding to each condition.

BobM> OK; BobM to fix.

        Item:      16
        Page:      12
        Clause:    5
        Qualifier: question
        Rationale: Is  it acceptable for appnNodeUpTime to wrap when sys-
                   tems stay up longer than about 497 days?

BobM> This sounds like a pretty esoteric problem to be worrying about.
BobM> How is this handled in other MIBs?

        Proposal:
        Item:      17
        Page:      12+
        Clause:    5
        Qualifier: minor
        Rationale: The "SYNTAX INTEGER { yes(1), no(2) }" appears  numer-
                   ous  times in this MIB.  A textual convention, such as
                   TruthValue from RFC 1903, would be  appropriate.   The
                   affected  definitions  are  appnNodeParallelTg, appnN-
                   odeAdaptiveBindPacing,     appnNodeNnCentralDirectory,
                   appnNodeNnIsr,  appnNodeNnPeriBorderSup, appnNodeNnIn-
                   terchangeSup, appnNodeNnExteBorderSup,  appnNodeNnCon-
                   gested,   appnNodeNnIsrDepleted,  appnNodeNnQuiescing,
                   appnNodeNnGateway,  appnNodeEnModeCosMap,  appnNodeEn-
                   LuSearch, appnPortSIMRIM, appnPortNegotLs, appnPortDy-
                   namicLinkSupport,  appnLsDynamic,   appnLsLimResource,
                   appnLsActOnDemand, appnLsMigration, appnLsCpCpSession-
                   Support, appnLsErrRecoSup, appnLsStatusRetry, appnNnN-
                   odeFRCongested,  appnNnNodeFRIsrDepleted,  appnNnNode-
                   FRQuiescing,    appnNnNodeFRGateway,     appnNnNodeFR-
                   CentralDirectory,    appnNnNodeFRIsr,    appnNnNodeFR-
                   GarbageCollect, appnNnNodeFRPeriBorderSup, appnNnNode-
                   FRInterchangeSup,  appnNnNodeFRExteBorderSup, appnNnT-
                   gFRDestVirtual, appnNnTgFROperational,  appnNnTgFRQui-
                   escing,   appnNnTgFRGarbageCollect,  appnNnTgFRHprSup,
                   appnNnTgFRDestHprTrans, appnNnTgFRIntersubnet, appnLo-
                   calTgDestVirtual, appnLocalTgQuiescing, appnLocalTgOp-
                   erational,                     appnLocalTgIntersubnet,
                   appnLocalEnTgDestVirtual,    appnLocalEnTgOperational,
                   appnCosNodeRowMinCongestAllow, and  appnCosNodeRowMax-
                   CongestAllow.

        Proposal:  Add  TruthValue  to  the  IMPORTS  list on page 9, and
                   update these definitions to make use of it.

BobM> OK; BobM to fix.

        Item:      18
        Page:      12+
        Clause:    5
        Qualifier: minor
        Rationale: The "SYNTAX INTEGER { noHprSupport(1), hprBaseOnly(2),
                   rtpTower(3),  controlFlowsOverRtpTower(4)}" appears in
                   several locations.  Introducing a  textual  convention
                   might  be  appropriate.  The definitions affected are:
                   appnNodeHprSupport, appnLsHprSup,  appnNnNodeFRHprSup-
                   port, and appnLocalTgHprSup.

        Proposal:  Add  a  textual convention and make use of it in these
                   definitions.

BobM> OK; BobM to fix.

        Item:      19
        Page:      13+
        Clause:    5
        Qualifier: minor
        Rationale: The mapping between the identified bit  positions  and
                   the  possible  enumerated values is not clear.  Imple-
                   mentation by offset and by masking would produce  dif-
                   ferent  results.   The mapping of the bit combinations
                   to the enumeration values  should  be  made  explicit.
                   The   definitions  affected  are:  appnNodeHprSupport,
                   appnNodeNnCentralDirectory, appnNodeNnIsr,  appnNodeN-
                   nPeriBorderSup,  appnNodeNnInterchangeSup,  appnNodeN-
                   nExteBorderSup, appnNodeNnCongested,  appnNodeNnIsrDe-
                   pleted,     appnNodeNnQuiescing,    appnNodeNnGateway,
                   appnNnNodeFRCongested,        appnNnNodeFRIsrDepleted,
                   appnNnNodeFRQuiescing,  appnNnNodeFRGateway,  appnNnN-
                   odeFRCentralDirectory, appnNnNodeFRIsr,  appnNnNodeFR-
                   GarbageCollect,  appnNnNodeFRHprSupport, appnNnNodeFR-
                   PeriBorderSup, appnNnNodeFRInterchangeSup, appnNnNode-
                   FRExteBorderSup, appnNnTgFROperational, appnNnTgFRQui-
                   escing,  appnNnTgFRCpCpSession,  appnNnTgFRGarbageCol-
                   lect,     appnNnTgFRHprSup,    appnNnTgFRDestHprTrans,
                   appnNnTgFRTypeIndicator, and appnNnTgFRIntersubnet.

        Proposal:  Identify the mapping between the various bit  combina-
                   tions and the enumeration values.

BobM> This seems unnecessary to me.  Most of these are just mapping a bit
BobM> in a CV to a TruthValue.  Where they aren't, an implementer who
BobM> reads SNA Formats shouldn't have any trouble deciding what to do.

        Item:      20
        Page:      13
        Clause:    5
        Qualifier: editorial
        Rationale: In  the  definition  of appnNodeMaxSessPerRtpConn, the
                   sense of "would" is unclear.

        Proposal:  Replace "would" with "is able to" (if that is what  is
                   meant).

BobM> OK; BobM to fix, but I'll double check first to make this is what
BobM> it really means.

        Item:      21
        Page:      13+
        Clause:    5
        Qualifier: minor
        Rationale: According  to  RFC 1902 clause 7.1.6, counters have no
                   defined initial value.  The definitions  affected  are
                   appnNodeHprIntRteSetups,     appnNodeHprIntRteRejects,
                   appnNodeHprOrgRteSetups,     appnNodeHprOrgRteRejects,
                   appnNodeHprEndRteSetups,     appnNodeHprEndRteRejects,
                   appnNnTopoNodePurges, appnNnTopoTgPurges, appnDirInLo-
                   cates,  appnDirInBcastLocates, appnDirOutLocates, app-
                   nDirOutBcastLocates, appnDirNotFoundLocates, and  app-
                   nDirNotFoundBcastLocates.

        Proposal:  Consider  whether the "initial value" specification is
                   needed.  Identify the TimeStamp discontinuity  indica-
                   tor  for these counters as required by RFC 1902 clause
                   7.1.6.

BobM> I'll add pointers to the "discontinuity indicators" for these
BobM> counters.  I'm not quite sure what point Randy is making about
BobM> initial values, though.

        Item:      22
        Page:      16
        Clause:    5
        Qualifier: major
        Rationale: Is the range of flow-reduction sequence numbers really
                   -2147483648  to  2147483647?  This affects the defini-
                   tions   of   appnNodeNnFrsn,   appnNnNodeFRFrsn,   and
                   appnNnTgFRFrsn.

        Proposal:  Since  this  are  used  as  indexes  in  the  case  of
                   appnNnTopologyFRTable,  and   appnNnTgTopologyFRTable,
                   and  negative  indexes  are not permitted, a syntax of
                   Unsigned32 would probably be appropriate.

BobM> OK; BobM to fix.

        Item:      23
        Page:      17
        Clause:    5
        Qualifier: editorial
        Rationale: In  the  definition  of  appnNodeNnSafeStoreFreq,  the
                   phrase  "even  multiple" is ambiguous.  It can be read
                   to mean "(updates modulo  appnNodeNnSafeStoreFreq)  ==
                   0"  or "(updates modulo (appnNodeNnSafeStoreFreq * 2))
                   == 0".

        Proposal:  Clarify whatever is meant.

BobM> OK; BobM to fix.

        Item:      24
        Page:      17+
        Clause:    5
        Qualifier: minor
        Rationale: The range of values permitted by the syntax for appnN-
                   odeNnSafeStoreFreq,           appnPortMaxIframeWindow,
                   appnLsCurrentDelay,  appnLsMaxDelay,   appnLsMinDelay,
                   and   appnNnTopoMaxNodes   is  inconsistent  with  its
                   description.

        Proposal:  Modify the SYNTAX to exclude negative values.  Gauge32
                   may be appropriate.

BobM> OK; BobM to fix.

        Item:      25
        Page:      17,56
        Clause:    5
        Qualifier: minor
        Rationale: Are  negative  resource  sequence  numbers  permitted?
                   This affects  the  definition  of  appnNodeNnRsn,  and
                   appnNnTgFRRsn.

        Proposal:  Use an appropriate syntax, such as Unsigned32.

BobM> OK; BobM to fix.

        Item:      26
        Page:      17+
        Clause:    5
        Qualifier: minor
        Rationale: The   mapping  between  multiple  byte  quantities  in
                   machine registers and integer  syntaxes  needs  to  be
                   clear  to avoid byte-ordering confusion.  This affects
                   the definition  of  appnNodeNnRsn,  appnPortMaxRcvBtu-
                   Size,   appnLsStatusXidByteInError,   appnNnNodeFRRsn,
                   appnNnTgFRRsn, and appnNnTgFRSubareaNum.

        Proposal:  Identify the byte order of the bytes being  mapped  to
                   this value.

BobM> I don't know what Randy is asking for here.  Any proposals?

        Item:      27
        Page:      19
        Clause:    5
        Qualifier: minor
        Rationale: The last two sentences of the description of appnPort-
                   Table are confusing.  They appear to be  making  appn-
                   PortSpecific  optional.  However, this is inconsistent
                   with the reference to "the value  of  IfIndex",  which
                   would be of the wrong type to use in this manner.

        Proposal:  Clarify  what is meant, ensuring that the syntaxes are
                   consistent and that the relevant objects  are  identi-
                   fied.

BobM> This may take a little work to clarify.  This is where we were
BobM> *trying* to have an object that could either point to an ifEntry
BobM> (if there was one), or if not, point to something else, or to
BobM> nothing.

        Item:      28
        Page:      20-21
        Clause:    5
        Qualifier: minor
        Rationale: The  last  sentence of the first paragraph of descrip-
                   tion text  for  appnPortAdminState,  appnLsAdminState,
                   and appnIsInGlobeCtrAdminStatus.  is incomprehensible.
                   If taken literally, the text would  suggest  that  the
                   initial  value  for  an  instance  of  this  object is
                   "ready", and that this value must be maintained  until
                   a  set  operation  is received.  It would also suggest
                   that a port cannot be used (be active)  until  manage-
                   ment   action   changes  the  state  from  "ready"  to
                   "active".  If this is true, then a system is  required
                   to  come up in a state inaccessible to management, and
                   is  not  permitted  to   allow   communication   until
                   management magically succeeds in setting this variable
                   to "active."  The text in the description of appnLsAc-
                   tOnDemand conflicts with this reading.

        Proposal:  Clarify whatever is really intended for this variable.

BobM> I'll clarify the text, since Randy has missed the admin versus
BobM> oper distinction (in this case).

        Item:      29
        Page:      23
        Clause:    5
        Qualifier: major
        Rationale: RFC 1902 clause 7.1.6 requires that counters which can
                   experience discontinuities at times other than manage-
                   ment system re-initialization must identify an  object
                   of  type  TimeStamp  which  can be monitored to detect
                   such discontinuities.  This affects the definition  of
                   appnPortDefLsGoodXids, appnPortDefLsBadXids, appnPort-
                   DynLsGoodXids, and appnPortDynLsBadXids.

        Proposal:  Add an appnPortStartedTimeStamp object to satisfy this
                   requirement.

BobM> This comment seems correct to me.  Do we want to add another
BobM> time stamp for these counters (presumably in our usual
BobM> DateAndTime format)?

        Item:      30
        Page:      24
        Clause:    5
        Qualifier: editorial
        Rationale: Is  the  concept of "unsuccessful XID exchanges" well-
                   defined?  Does it include failure to respond, protocol
                   errors, and so on?  This affects appnPortDefLsBadXids,
                   appnPortDynLsBadXids, and appnLsBadXids

        Proposal:  Identify exactly what is being counted.

BobM> OK; BobM to fix.

        Item:      31
        Page:      24
        Clause:    5
        Qualifier: minor
        Rationale: Is this item intended to be a pointer?   This  affects
                   the  definition  of  appnPortSpecific,  and appnLsSpe-
                   cific.

        Proposal:  Use the RowPointer textual convention from  RFC  1903.
                   Identify the value to be used when no object exists to
                   supply additional information.

BobM> See item 27 above.  I don't think RowPointer does all that we're
BobM> trying to do with this object.  Comments?

        Item:      32
        Page:      24+
        Clause:    5
        Qualifier: minor
        Rationale: The mapping from addresses to DisplayString  represen-
                   tation needs to be defined.

        Proposal:  Modify  the definition of appnPortDlcLocalAddr, appnL-
                   sLocalAddr,  appnLsRemoteAddr,  appnLsStatusLocalAddr,
                   and  appnLsStatusRemoteAddr to describe the mapping of
                   addresses into DisplayString form.  If these  mappings
                   follow  a  pattern, a textual convention may be appro-
                   priate.

BobM> We decided to leave this unspecified in the MIB.  For "old" DLCs
BobM> we're assuming that the format is obvious.  For "new" ones, we'll
BobM> specify it explicitly in an architecture document, as we did in
BobM> Gary Dudley's for HPR over ATM.

        Item:      33
        Page:      31
        Clause:    5
        Qualifier: editorial
        Rationale: Missing word.

        Proposal:  Add "maximum" between "desired" and  "number"  in  the
                   first sentence of the description of appnLsMaxSendBtu-
                   Size.

BobM> I'll look into this.  I'm not sure Randy's hypothesis is correct
BobM> here.

        Item:      34
        Page:      31
        Clause:    5
        Qualifier: minor/editorial
        Rationale: Missing reference in the second paragraph of the defi-
                   nition of appnLsMaxSendBtuSize.

        Proposal:  The  variable  which  defines  "activating"  should be
                   identified.  There is currently no variable in the MIB
                   with this as a possible value.

BobM> I'll look into this.

        Item:      35
        Page:      31+
        Clause:    5
        Qualifier: minor
        Rationale: RFC 1902 clause 7.1.6 suggests that it would be appro-
                   priate to identify how discontinuities in counters may
                   be   detected.    For  the  objects  appnLsInXidBytes,
                   appnLsInMsgBytes,    appnLsInXidFrames,    appnLsInMs-
                   gFrames,  appnLsOutXidBytes, appnLsOutMsgBytes, appnL-
                   sOutXidFrames    appnLsOutMsgFrames    appnLsEchoRsps,
                   appnLsGoodXids,  and appnLsBadXids no such objects are
                   identified.

        Proposal:  Decide whether these counts are  maintained  over  the
                   lifetime  of  the  system or have some other lifetime,
                   and update the definitions accordingly.

BobM> This is basically the same comment as item 23 above, but we must
BobM> be wearing Randy down:  23 was major, but this one's only minor;-).
BobM> Do we want yet another DateAndTime here?

        Item:      36
        Page:      31+
        Clause:    5
        Qualifier: minor
        Rationale: Are the ways in which XID bytes,  and  I-frame  bytes,
                   are   counted   well-agreed?    The   definitions   of
                   appnLsInXidBytes, appnLsInMsgBytes, appnLsOutXidBytes,
                   and appnLsOutMsgBytes leave much to the imagination.

        Proposal:  Define  exactly  which  bytes are counted or provide a
                   reference to the document which  defines  which  bytes
                   are included in these counts.

BobM> OK; BobM to fix.

        Item:      37
        Page:      33
        Clause:    5
        Qualifier: editorial
        Rationale: Missing word.

        Proposal:  Insert "echo" before "responses" in the first sentence
                   of the description of appnLsEchoRsps.

BobM> OK; BobM to fix.

        Item:      38
        Page:      33,34
        Clause:    5
        Qualifier: minor
        Rationale: The semantics of gauges recording maximum  of  minimum
                   observed  values  logically require definition of ini-
                   tial values to handle  the  case  when  the  gauge  is
                   observed before the measured condition has occurred.

        Proposal:  Add appropriate initial values to the description text
                   for  appnLsMaxDelay,  appnLsMinDelay,  appnLsMaxDelay-
                   Time.

BobM> OK; BobM to fix.

        Item:      39
        Page:      35
        Clause:    5
        Qualifier: minor
        Rationale: The  description  of  appnLsActiveTime is inconsistent
                   with the semantics of TimeTicks in clause 7.1.8 of RFC
                   1902.   Also,  it is unclear whether "node activation"
                   is the same thing as "node re-initialization".

        Proposal:  Use Unsigned32 syntax for this  information.   Clarify
                   what is meant by "node activation".

BobM> OK; BobM to fix.

        Item:      40
        Page:      38
        Clause:    5
        Qualifier: editorial
        Rationale: The  comment makes a broader statement than was proba-
                   bly intended.

        Proposal:  Delete both occurrances of the word "all."

BobM> OK; BobM to fix.

        Item:      41
        Page:      38
        Clause:    5
        Qualifier: question
        Rationale: Is there  agreement  on  when  entries  are  added  to
                   appnLsStatusTable?

        Proposal:  Identify when entries are added.

BobM> What can we say here?  I'm not sure whether Randy is asking in
BobM> what situations/scenarios entries are added, or at exactly what
BobM> point in time they're added in these scenarios.

        Item:      42
        Page:      38
        Clause:    5
        Qualifier: minor
        Rationale: The  description of appnLsStatusEntry is not satisfied
                   by the behavior of appnLsStatusIndex.   After  a  wrap
                   has occurred, GET-NEXT will not be limited to retriev-
                   ing only updates to the table.

        Proposal:  Clarify the algorithm for retrieving updates  to  make
                   use  of  appnLsStatusTime  as a termination condition.
                   Note that this  will  not  be  of  use  with  GET-BULK
                   retrieval.

BobM> Clearly this index will never wrap in practice, so what should we
BobM> say here?

        Item:      43
        Page:      39
        Clause:    5
        Qualifier: question
        Rationale: Are  all  the  columns identified in AppnLsStatusEntry
                   present for all rows?  Meaningful values appear to  be
                   defined for all columns.

        Proposal:  Identify  explicitly  any columns which are not always
                   present in all rows.

BobM> We need to think about this one.  Thoughts?

        Item:      44
        Page:      39
        Clause:    5
        Qualifier: minor
        Rationale: The description of appnLsStatusTime gives  an  example
                   that  is  not  supported  by the rest of the MIB.  The
                   "last the the APPN node  was  re-initialized"  is  not
                   available as DateAndTime.

        Proposal:  Either change the example or add the missing object.

BobM> I guess Randy's right about this.  A Management Station can
BobM> retrieve appnUpTime and get an approximate DateAndTime when the
BobM> node was last re-initialized.  Is this good enough?

        Item:      45
        Page:      44
        Clause:    5
        Qualifier: question
        Rationale: For  appnVrnName, is the intent for the definitions to
                   make use of the same format as is  defined  for,  e.g,
                   appnNodeEnNnServer?

        Proposal:  If so, make use of a common textual convention.

BobM> OK; BobM to fix as part of overall textual conventions.

        Item:      46
        Page:      46
        Clause:    5
        Qualifier: question
        Rationale: Is  the  implementation choice allowed in the descrip-
                   tion of appnNnTopoMaxNodes  and  appnNnTopoCurNumNodes
                   in the best interest of interoperability?  Can statis-
                   tics collected using the two algorithms be combined in
                   any meaningful way?

        Proposal:  Pick one of the algorithms.  There is a clear require-
                   ment (though not explicit in the MIB definition)  that
                   the same choice be made for both objects.

BobM> We'll need to look at the APPN architecture for TRS here.  At the
BobM> very least, Randy's correct that a single node should use the same
BobM> algorithm for both of these objects.

        Item:      47
        Page:      49
        Clause:    5
        Qualifier: editorial
        Rationale: The  description  of  appnNnNodeFREntryTimeLeft allows
                   more  implementation   freedom   than   was   probably
                   intended.

        Proposal:  Replace "this or the next" with something clearer.

BobM> I'll check the architecture on this point.

        Item:      48
        Page:      50
        Clause:    5
        Qualifier: question
        Rationale: Is  the  range of permitted values for appnNnNodeFRRsn
                   really -2147483648 to 2147483647?

        Proposal:  Use Unsigned32.

BobM> OK; BobM to fix.

        Item:      49
        Page:      56,70
        Clause:    5
        Qualifier: editorial
        Rationale: The current  description  of  appnNnTgFREntryTimeLeft,
                   appnLocalEnTgEntryTimeLeft, and does not make it clear
                   what a value of zero means.

        Proposal:  Add clarifying text.

BobM> OK; BobM to fix.

        Item:      50
        Page:      56,64,71
        Clause:    5
        Qualifier: minor
        Rationale: The description of appnNnTgFRDlcData,  appnLocalTgDlc-
                   Data,  and appnLocalEnTgDlcData does not make it clear
                   how the various address types are mapped into an octet
                   string.  For example, are X.25 dial digits represented
                   as a character string, binary digits, packed  BCD,  or
                   something else?

        Proposal:  Describe  the  mapping  used for each of the examples,
                   and provide guidelines for determining the mapping  to
                   be  used  for  other  types.  It may be appropriate to
                   define a textual convention for these objects.

BobM> See item 32 above.

        Item:      51
        Page:      57,65,71
        Clause:    editorial
        Qualifier:
        Rationale: The  syntax  of   appnNnTgFRCpCpSession,   appnLocalT-
                   gCpCpSession,  and appnLocalEnTgCpCpSession is identi-
                   cal, and may be appropriate for definition as  a  tex-
                   tual convention.

        Proposal:  Consider whether the use of a textual convention would
                   enhance readability.

BobM> I think that a textual convention here enhances maintainability
BobM> at the cost of *decreased* readability, but I'll go ahead and
BobM> add the textual convention unless somebody thinks I shouldn't.

        Item:      52
        Page:      58,65,72,86
        Clause:    editorial
        Qualifier:
        Rationale: The definitions of  appnNnTgFREffCap,  appnLocalTgEff-
                   Cap,  appnLocalEnTgEffCap,  appnCosTgRowEffCapMin, and
                   appnCosTgRowEffCapMax all refer  to  the  encoding  of
                   byte 7 of cv47.

        Proposal:  Consider whether the use of a textual convention would
                   enhance readability.

BobM> OK; BobM to fix.

        Item:      53
        Page:      59,67,73,89
        Clause:    editorial
        Qualifier:
        Rationale: The definitions of appnNnTgFRDelay,  appnLocalTgDelay,
                   appnLocalEnTgDelay,  appnCosTgRowDelayMin,  and  appn-
                   CosTgRowDelayMax all refer to the encoding of byte  17
                   of cv47.

        Proposal:  Consider whether the use of a textual convention would
                   enhance readability.

BobM> OK; BobM to fix.

        Item:      54
        Page:      59+
        Clause:    5
        Qualifier: minor
        Rationale: In the description of appnNnTgFRSecurity,  appnLocalT-
                   gSecurity,  appnLocalEnTgSecurity, appnCosTgRowSecuri-
                   tyMin,  and  appnCosTgRowSecurityMax,  it  is  unclear
                   which  of the specified values should be used when the
                   user-defined characteristics are  used.   (The  phrase
                   "other than the ones defined here" makes it sound like
                   some value other than the ones permitted by  the  enu-
                   meration  might be used, contrary to the syntax speci-
                   fication.)

        Proposal:  Identify the value(s) to be used in the "other"  case.
                   A textual convention may be appropriate.

BobM> Randy's misreading this, so I'll see if I can clarify it.

        Item:      55
        Page:      60+
        Clause:    5
        Qualifier: editorial
        Rationale: The  descriptions  of  appnNnTgFRUsr1, appnNnTgFRUsr2,
                   appnNnTgFRUsr3,   appnLocalTgUsr1,    appnLocalTgUsr2,
                   appnLocalTgUsr3, appnLocalEnTgUsr1, appnLocalEnTgUsr2,
                   appnLocalEnTgUsr3,   appnCosTgRowUsr1Min,    appnCosT-
                   gRowUsr1Max, appnCosTgRowUsr2Min, appnCosTgRowUsr2Max,
                   appnCosTgRowUsr3Min,   and   appnCosTgRowUsr3Max   are
                   rather vacuous.

        Proposal:  If  possible, pin down just what these variables mean.

BobM> I'll check, but I suspect that the descriptions capture every
BobM> shred of information that's there in the architecture itself.

        Item:      56
        Page:      61
        Clause:    5
        Qualifier: question
        Rationale: The syntax of appnNnTgFRSubareaNum  would  imply  that
                   negative  subarea  numbers  are  permitted.   Is  this
                   intentional?

        Proposal:  Choose an appropriate syntax, such as Unsigned32.

BobM> OK; BobM to fix.

        Item:      57
        Page:      69
        Clause:    5
        Qualifier: editorial
        Rationale: The second sentence of the  description  of  appnLoca-
                   lEnTgTable is odd.  This sentence tells us what is not
                   in the table, but doesn't  tell  us  what  is  in  the
                   table.

        Proposal:  Clarify.

BobM> OK; BobM to fix.

        Item:      58
        Page:      74
        Clause:    5
        Qualifier: Major
        Rationale: The syntax of appnDirMaxCaches is in conflict with the
                   object's  semantics  and  the  syntaxes   of   related
                   objects.  Negative cache sizes are not meaningful.

        Proposal:  Change the syntax to Unsigned32.

BobM> OK; BobM to fix.

        Item:      59
        Page:      78
        Clause:    5
        Qualifier: editorial
        Rationale: There  is  a missing "'" at the end of the description
                   of appnDirLuOwnerName.  Also,  the  format  "ccc*"  is
                   unclear  as  to whether "ccc" represents exactly three
                   characters or one to sixteen characters.

        Proposal:  Change /'*"/ to /'*'"/, and clarify what is  meant  by
                   "ccc".

BobM> OK; BobM to fix.

        Item:      60
        Page:      84
        Clause:    5
        Qualifier: editorial
        Rationale: The description text for appnCosNodeRowMinCongestAllow
                   and appnCosNodeRowMaxCongestAllow is incomprehensible.

        Proposal:  Clarify what is meant.

BobM> OK; BobM to fix.

        Item:      61
        Page:      92
        Clause:    5
        Qualifier: editorial
        Rationale: The second paragraph of description text for appnIsIn-
                   GlobeCtrAdminStatus is confusing, especially in  light
                   of  the following paragraph.  For example, none of the
                   objects referred to are counters.

        Proposal:  Identify the objects, and refer to the collected  data
                   as  "counts"  rather  than  "counters".   Make similar
                   adjustments    to    the    description    text     of
                   appnIsInGlobeCtrOperStatus.

BobM> I'm not sure I agree with Randy's premise that SMI has reserved the
BobM> word "counter" for its Counternn syntaxes, but I'll clarify this
BobM> text.

        Item:      62
        Page:      96
        Clause:    5
        Qualifier: Major
        Rationale: The  labels and values of the enumeration for the syn-
                   tax of appnIsInSessState do not match the  description
                   text.

        Proposal:  Align the syntax and the description.

BobM> OK; BobM to fix.

        Item:      63
        Page:      99
        Clause:    5
        Qualifier: minor
        Rationale: The UNITS clauses on appnIsInSessUpTime and appnIsInC-
                   trUpTime are superfluous; the units  are  inherent  in
                   the definition of TimeTicks.

BobM> OK; BobM to fix.

        Item:      64
        Page:      99+
        Clause:    5
        Qualifier: minor
        Rationale: The syntax for appnIsInP2SFmdPius, appnIsInS2PFmdPius,
                   appnIsInP2SNonFmdPius, appnIsInS2PNonFmdPius,  appnIs-
                   InP2SFmdBytes, appnIsInS2PFmdBytes, appnIsInP2SNonFmd-
                   Bytes, and appnIsInS2PNonFmdBytes does not  match  the
                   object   semantics.    In   particular,   a  range  of
                   -2147483648 to 2147483647 is not meaningful  for  what
                   are really counts.

        Proposal:  Unsigned32  would  be more appropriate.  It would also
                   be helpful to explicitly reference appnIsInGlobeCtrAd-
                   minStatus in the descriptions, and to refer to them as
                   counts rather than counters.

BobM> OK; BobM to fix.

        Item:      65
        Page:      102
        Clause:    5
        Qualifier: minor
        Rationale: It would be helpful to provide UNITS clauses for  app-
                   nIsInPsSendRpc,    appnIsInPsSendNxWndwSize,   appnIs-
                   InPsRecvRpc,      appnIsInPsRecvNxWndwSize,       app-
                   nIsInSsSendRpc,  appnIsInSsSendNxWndwSize, appnIsInSs-
                   RecvRpc, appnIsInSsRecvNxWndwSize,  and  appnIsRtpSes-
                   sions.

        Proposal:  Add UNITS clauses.

BobM> OK; BobM to fix.

        Item:      66
        Page:      105
        Clause:    5
        Qualifier: minor
        Rationale: The  description  text  for appnIsInRouteInfo does not
                   make it clear whether "not  present"  means  that  the
                   object  does  not  exist or that it should have a spe-
                   cific value, such as a zero length string.

        Proposal:  Clarify what is meant by "not present."

BobM> OK; BobM to fix.

        Item:      67
        Page:      108
        Clause:    5
        Qualifier: questions
        Rationale: For alertIdNumber and affectedObject, was  the  inten-
                   tion  for these objects to be "read-only" or "accessi-
                   ble-for-notify"?

        Proposal:  Specify the value  taken  by  affectedObject  when  no
                   object  is  associated  with  the  alert  in question.
                   Depending on the alerts, it may be appropriate for  it
                   to have a RowPointer syntax.

BobM> OK; BobM to fix.  I think the intent here was for these objects
BobM> to be accessible-for-notify.

        Item:      68
        Page:      119
        Clause:    5
        Qualifier: minor
        Rationale: For appnTrapConfGroup, it might by more appropriate to
                   describe it as a  NOTIFICATION-GROUP  than  an  OBJECT
                   group.

        Proposal:  Re-cast appnTrapConfGroup as a NOTIFICATION-GROUP

BobM> OK; BobM to fix, but I think we need *both* an OBJECT-GROUP and a
BobM> NOTIFICATION-GROUP.

        Item:      69
        Page:      120
        Clause:    7
        Qualifier: editorial
        Rationale: References [9] and [13] are incomplete.

        Proposal:  Complete the references.

BobM> OK; BobC to fix.

---

From: Randy Presuhn <[email-masked]>
Date: Tue, 20 Aug 1996 15:50:23 -0700

Hi -

Because my role here is as a reviewer, rather than as a contributor, I
did not break this into separate threads.

This message contains clarifications (I hope) to the review comments,
resulting from Bob Moore's preliminary proposed disposition of comments.
See Bob's message for the complete list; I've only included the items
where I felt I needed to clarify or expand on the original comment or
Bob's proposed resolution.

|Message-Id: <[email-masked]>
|Date: Tue, 20 Aug 96 14:41:59 EDT
|From: "R.E. (Robert) Moore (254-4436)" <[email-masked]>
|To: [email-masked], [email-masked]
|Subject:  First response to Randy Presuhn's APPN MIB comments
|Status: RO
...
|        Item:      1
|        Page:      -
|        Clause:    -
|        Qualifier: general
|        Rationale: The definitions of the  tables  appnPortTable,  appnL-
|                   sTable, appnLsStatusTable, appnVrnTable, appnNnTopolo-
|                   gyFRTable, appnNnTgTopologyFRTable,  appnLocalTgTable,
|                   appnLocalEnTgTable,   appnDirTable,  appnCosModeTable,
|                   appnCosNameTable,    appnCosNodeRowTable,    appnCosT-
|                   gRowTable,  appnIsInTable,  and  appnIsRtpTable do not
|                   describe the conditions under which entries are  added
|                   or deleted.  The MIB definitions do not provide a low-
|                   overhead mechanism for detecting changes to tables.
|
|        Proposal:  Make the decision to do this a conscious one.
|
|BobM> We'll need to respond to Randy, saying that the decision was a
|BobM> conscious one, and that while it's unusual, we *do* have a low-
|BobM> overhead way of detecting changes to the FR tables.

When there is a specific scenario for the use of a particular variable,
or there's a need to detect changes in a particular table, it's helpful
to spell out what the MIB designers had in  mind.

|        Item:      2
|        Page:      -
|        Clause:    -
|        Qualifier: general
|        Rationale: The way the definitions are currently written make  it
|                   impossible  for  a future version of this MIB to allow
|                   management operations  to  create/delete  table  rows,
|                   modify configuration parameters, and so on.
|
|        Proposal:  Make  the  decision  to  do  this a conscious one.  If
|                   there is a realistic possibility that management  con-
|                   trol will be needed, it would make sense to modify the
|                   relevant MAX-ACCESS clauses from "read-only" to "read-
|                   write"  or "read-create", and to use the MIN-ACCESS in
|                   the MODULE-COMPLIANCE section to set  the  "read-only"
|                   expectation.
|
|BobM> We'll need to respond to Randy, saying that the decision was a
|BobM> conscious one.

Fine.

...
|        Item:      10
|        Page:      -
|        Clause:    -
|        Qualifier: editorial
|        Rationale: Several abbreviations are not  expanded  before  being
|                   used,  although  in  some  cases  an expansion appears
|                   later in the text.  Though  most  of  these  would  be
|                   fairly  obvious  to  the SNA-aware, the lack of expan-
|                   sions is inconsistent  with  the  expansion  of  other
|                   basic SNA-isms in this document.
|
|                   ABM,  ACTPU, ANR, APPC, CS, CV22, DLUR, FMD, HPR, LLC,
|                   LU, MAC, MS, MU, NAU, NCE, NRM, PIU,  RSCV,  RTP,  RU,
|                   SAP, SDLC, SNA, SSCP, TDU, XID.
|
|        Proposal:  Add the missing definitions as needed.
|
|BobM> I agree with the comment, but I'm not sure how/where to put the
|BobM> expansions for these acronyms.  Any suggestions?

I'd suggest adding the expansion to the first use of each of these.

...
|        Item:      16
|        Page:      12
|        Clause:    5
|        Qualifier: question
|        Rationale: Is  it acceptable for appnNodeUpTime to wrap when sys-
|                   tems stay up longer than about 497 days?
|
|BobM> This sounds like a pretty esoteric problem to be worrying about.
|BobM> How is this handled in other MIBs?

It depends on what this variable is supposed to be used for.

...
|        Item:      19
|        Page:      13+
|        Clause:    5
|        Qualifier: minor
|        Rationale: The mapping between the identified bit  positions  and
|                   the  possible  enumerated values is not clear.  Imple-
|                   mentation by offset and by masking would produce  dif-
|                   ferent  results.   The mapping of the bit combinations
|                   to the enumeration values  should  be  made  explicit.
|                   The   definitions  affected  are:  appnNodeHprSupport,
|                   appnNodeNnCentralDirectory, appnNodeNnIsr,  appnNodeN-
|                   nPeriBorderSup,  appnNodeNnInterchangeSup,  appnNodeN-
|                   nExteBorderSup, appnNodeNnCongested,  appnNodeNnIsrDe-
|                   pleted,     appnNodeNnQuiescing,    appnNodeNnGateway,
|                   appnNnNodeFRCongested,        appnNnNodeFRIsrDepleted,
|                   appnNnNodeFRQuiescing,  appnNnNodeFRGateway,  appnNnN-
|                   odeFRCentralDirectory, appnNnNodeFRIsr,  appnNnNodeFR-
|                   GarbageCollect,  appnNnNodeFRHprSupport, appnNnNodeFR-
|                   PeriBorderSup, appnNnNodeFRInterchangeSup, appnNnNode-
|                   FRExteBorderSup, appnNnTgFROperational, appnNnTgFRQui-
|                   escing,  appnNnTgFRCpCpSession,  appnNnTgFRGarbageCol-
|                   lect,     appnNnTgFRHprSup,    appnNnTgFRDestHprTrans,
|                   appnNnTgFRTypeIndicator, and appnNnTgFRIntersubnet.
|
|        Proposal:  Identify the mapping between the various bit  combina-
|                   tions and the enumeration values.
|
|BobM> This seems unnecessary to me.  Most of these are just mapping a bit
|BobM> in a CV to a TruthValue.  Where they aren't, an implementer who
|BobM> reads SNA Formats shouldn't have any trouble deciding what to do.

The point is that if there is a bit field supporting the values 0 and
1, there are two possible mappings to a TruthValue syntax.  I've seen
things like this mis-implemented.  If the group is convinced that the
relevant SNA documents remove all ambiguities when it comes time to do
the mappings, I'll be satisfied.

...
|        Item:      21
|        Page:      13+
|        Clause:    5
|        Qualifier: minor
|        Rationale: According  to  RFC 1902 clause 7.1.6, counters have no
|                   defined initial value.  The definitions  affected  are
|                   appnNodeHprIntRteSetups,     appnNodeHprIntRteRejects,
|                   appnNodeHprOrgRteSetups,     appnNodeHprOrgRteRejects,
|                   appnNodeHprEndRteSetups,     appnNodeHprEndRteRejects,
|                   appnNnTopoNodePurges, appnNnTopoTgPurges, appnDirInLo-
|                   cates,  appnDirInBcastLocates, appnDirOutLocates, app-
|                   nDirOutBcastLocates, appnDirNotFoundLocates, and  app-
|                   nDirNotFoundBcastLocates.
|
|        Proposal:  Consider  whether the "initial value" specification is
|                   needed.  Identify the TimeStamp discontinuity  indica-
|                   tor  for these counters as required by RFC 1902 clause
|                   7.1.6.
|
|BobM> I'll add pointers to the "discontinuity indicators" for these
|BobM> counters.  I'm not quite sure what point Randy is making about
|BobM> initial values, though.

The idea of counter initial values is disparaged in RFC 1902 clause 7.1.6
second paragraph.  It doesn't really bother me personally, though in
general a management application should only operate on the derivative.
The comment is making two points:

	1) the need to identify discontinuity indicators
	2) whether the specification of an initial value of 0 is necessary

...
|        Item:      26
|        Page:      17+
|        Clause:    5
|        Qualifier: minor
|        Rationale: The   mapping  between  multiple  byte  quantities  in
|                   machine registers and integer  syntaxes  needs  to  be
|                   clear  to avoid byte-ordering confusion.  This affects
|                   the definition  of  appnNodeNnRsn,  appnPortMaxRcvBtu-
|                   Size,   appnLsStatusXidByteInError,   appnNnNodeFRRsn,
|                   appnNnTgFRRsn, and appnNnTgFRSubareaNum.
|
|        Proposal:  Identify the byte order of the bytes being  mapped  to
|                   this value.
|
|BobM> I don't know what Randy is asking for here.  Any proposals?

Readers may be familiar with both big-endian and little-endian machines,
as well as ones with no notion of "byte" at all.  If memory serves me,
S/360 was big-endian.  80x86 boxes are mostly little-endian.  I've worked
on machines where the CPU and peripherals had different byte-ordering. 

The following snippet will do different things on these two kinds of
machines:

{
	union	u
	{
		unsigned char	elements[2];
		unsigned short	single_thing;
	} u;

	u.elements[0] = 0;
	u.elements[1] = 1;
	printf("%d\n", u.single_thing);
}

Code that will do the same thing on both byte-oriented architectures:
{
	unsigned char	elements[2];
	unsigned short	single_thing;

	elements[0] = 0;
	elements[1] = 1;
	single_thing = elements[0];
	single_thing |= ((unsigned short) elements[1]) << 8;
	printf("%d\n", single_thing);
}

However, this may (or may not) be what was intended by the MIB's
designer, depending on what underlying byte/bit ordering was in mind.
If the designer's mental model was big endian, the results will be right.
If it was little-endian, they will be incorrect whenever the two bytes
have different values.

...
|        Item:      28
|        Page:      20-21
|        Clause:    5
|        Qualifier: minor
|        Rationale: The  last  sentence of the first paragraph of descrip-
|                   tion text  for  appnPortAdminState,  appnLsAdminState,
|                   and appnIsInGlobeCtrAdminStatus.  is incomprehensible.
|                   If taken literally, the text would  suggest  that  the
|                   initial  value  for  an  instance  of  this  object is
|                   "ready", and that this value must be maintained  until
|                   a  set  operation  is received.  It would also suggest
|                   that a port cannot be used (be active)  until  manage-
|                   ment   action   changes  the  state  from  "ready"  to
|                   "active".  If this is true, then a system is  required
|                   to  come up in a state inaccessible to management, and
|                   is  not  permitted  to   allow   communication   until
|                   management magically succeeds in setting this variable
|                   to "active."  The text in the description of appnLsAc-
|                   tOnDemand conflicts with this reading.
|
|        Proposal:  Clarify whatever is really intended for this variable.
|
|BobM> I'll clarify the text, since Randy has missed the admin versus
|BobM> oper distinction (in this case).

I don't think it's a question of administrative versus operational state.
It's pretty clear that this is intended as an administrative control.
The question is what is meant by "returned in response to a get operation
if no set operation has been directed to this object."  It makes it
sound like the object needs to remember whether it has ever been the
target of a set operation, successful or not.  One wonders why the
"ready" value is needed at all.

|
|        Item:      29
|        Page:      23
|        Clause:    5
|        Qualifier: major
|        Rationale: RFC 1902 clause 7.1.6 requires that counters which can
|                   experience discontinuities at times other than manage-
|                   ment system re-initialization must identify an  object
|                   of  type  TimeStamp  which  can be monitored to detect
|                   such discontinuities.  This affects the definition  of
|                   appnPortDefLsGoodXids, appnPortDefLsBadXids, appnPort-
|                   DynLsGoodXids, and appnPortDynLsBadXids.
|
|        Proposal:  Add an appnPortStartedTimeStamp object to satisfy this
|                   requirement.
|
|BobM> This comment seems correct to me.  Do we want to add another
|BobM> time stamp for these counters (presumably in our usual
|BobM> DateAndTime format)?

RFC 1902 clause 7.1.6 second paragraph requires a TimeStamp syntax.
(One can argue whether that's really the best representation, but 1902
is pretty explicit on this point.)

...
|        Item:      32
|        Page:      24+
|        Clause:    5
|        Qualifier: minor
|        Rationale: The mapping from addresses to DisplayString  represen-
|                   tation needs to be defined.
|
|        Proposal:  Modify  the definition of appnPortDlcLocalAddr, appnL-
|                   sLocalAddr,  appnLsRemoteAddr,  appnLsStatusLocalAddr,
|                   and  appnLsStatusRemoteAddr to describe the mapping of
|                   addresses into DisplayString form.  If these  mappings
|                   follow  a  pattern, a textual convention may be appro-
|                   priate.
|
|BobM> We decided to leave this unspecified in the MIB.  For "old" DLCs
|BobM> we're assuming that the format is obvious.  For "new" ones, we'll
|BobM> specify it explicitly in an architecture document, as we did in
|BobM> Gary Dudley's for HPR over ATM.

I'm not sure the mappings are really that obvious, but I haven't been
involved in the discussions.  Presumably these are addresses that can
show up in protocol.  Three concerns arise:
	1) that the limitations of the DisplayString textual convention
	   do not prevent the representation of a legitimate address
	2) that management systems (from multiple vendors) be able to
	   handle values reported by instrumentation (from multiple
	   vendors).
	3) that the "same" address be represented consistently by
	   different implementations.  Since these appear to be used
	   to identify both the near and the far ends, trouble shooting
	   applications that attempt to query the equpment at both ends
	   need to be able to match things up.

...
|        Item:      35
|        Page:      31+
|        Clause:    5
|        Qualifier: minor
|        Rationale: RFC 1902 clause 7.1.6 suggests that it would be appro-
|                   priate to identify how discontinuities in counters may
|                   be   detected.    For  the  objects  appnLsInXidBytes,
|                   appnLsInMsgBytes,    appnLsInXidFrames,    appnLsInMs-
|                   gFrames,  appnLsOutXidBytes, appnLsOutMsgBytes, appnL-
|                   sOutXidFrames    appnLsOutMsgFrames    appnLsEchoRsps,
|                   appnLsGoodXids,  and appnLsBadXids no such objects are
|                   identified.
|
|        Proposal:  Decide whether these counts are  maintained  over  the
|                   lifetime  of  the  system or have some other lifetime,
|                   and update the definitions accordingly.
|
|BobM> This is basically the same comment as item 23 above, but we must
|BobM> be wearing Randy down:  23 was major, but this one's only minor;-).
|BobM> Do we want yet another DateAndTime here?

This one was minor because one COULD say that system lifetime was the
one use, though I don't think that was the intent.  If an indicator is
added, for better or worse RFC1902 says it has to be TimeStamp.

...
|        Item:      41
|        Page:      38
|        Clause:    5
|        Qualifier: question
|        Rationale: Is there  agreement  on  when  entries  are  added  to
|                   appnLsStatusTable?
|
|        Proposal:  Identify when entries are added.
|
|BobM> What can we say here?  I'm not sure whether Randy is asking in
|BobM> what situations/scenarios entries are added, or at exactly what
|BobM> point in time they're added in these scenarios.

The phrase "this includes" in the excerpt is what triggered my question.

-- This table provides information about errors this node encountered
-- with connections to adjacent nodes.  This includes all exceptional
-- conditions encountered establishing connections and all exceptional
-- conditions that resulted in termination of a connection.  

What other conditions were envisioned?  Is all the information necessary
to create an entry available at the time the condition is detected?

..
|        Item:      51
|        Page:      57,65,71
|        Clause:    editorial
|        Qualifier:
|        Rationale: The  syntax  of   appnNnTgFRCpCpSession,   appnLocalT-
|                   gCpCpSession,  and appnLocalEnTgCpCpSession is identi-
|                   cal, and may be appropriate for definition as  a  tex-
|                   tual convention.
|
|        Proposal:  Consider whether the use of a textual convention would
|                   enhance readability.
|
|BobM> I think that a textual convention here enhances maintainability
|BobM> at the cost of *decreased* readability, but I'll go ahead and
|BobM> add the textual convention unless somebody thinks I shouldn't.

I'm satisfied as long the group has considered whether a TC would help
or hinder.

...
|        Item:      55
|        Page:      60+
|        Clause:    5
|        Qualifier: editorial
|        Rationale: The  descriptions  of  appnNnTgFRUsr1, appnNnTgFRUsr2,
|                   appnNnTgFRUsr3,   appnLocalTgUsr1,    appnLocalTgUsr2,
|                   appnLocalTgUsr3, appnLocalEnTgUsr1, appnLocalEnTgUsr2,
|                   appnLocalEnTgUsr3,   appnCosTgRowUsr1Min,    appnCosT-
|                   gRowUsr1Max, appnCosTgRowUsr2Min, appnCosTgRowUsr2Max,
|                   appnCosTgRowUsr3Min,   and   appnCosTgRowUsr3Max   are
|                   rather vacuous.
|
|        Proposal:  If  possible, pin down just what these variables mean.
|
|BobM> I'll check, but I suspect that the descriptions capture every
|BobM> shred of information that's there in the architecture itself.

Can't ask for more than that. :-)

...
|        Item:      61
|        Page:      92
|        Clause:    5
|        Qualifier: editorial
|        Rationale: The second paragraph of description text for appnIsIn-
|                   GlobeCtrAdminStatus is confusing, especially in  light
|                   of  the following paragraph.  For example, none of the
|                   objects referred to are counters.
|
|        Proposal:  Identify the objects, and refer to the collected  data
|                   as  "counts"  rather  than  "counters".   Make similar
|                   adjustments    to    the    description    text     of
|                   appnIsInGlobeCtrOperStatus.
|
|BobM> I'm not sure I agree with Randy's premise that SMI has reserved the
|BobM> word "counter" for its Counternn syntaxes, but I'll clarify this
|BobM> text.

I wasn't claiming that SMI had such restrictions.  That's why I called
this one "editorial."  I stumbled when reading, and suggested smoothing
the path.

|        Item:      68
|        Page:      119
|        Clause:    5
|        Qualifier: minor
|        Rationale: For appnTrapConfGroup, it might by more appropriate to
|                   describe it as a  NOTIFICATION-GROUP  than  an  OBJECT
|                   group.
|
|        Proposal:  Re-cast appnTrapConfGroup as a NOTIFICATION-GROUP
|
|BobM> OK; BobM to fix, but I think we need *both* an OBJECT-GROUP and a
|BobM> NOTIFICATION-GROUP.

I think you're right.

 -------------------------------------------------------------------------
 Randy Presuhn            PEER Networks, a division of BMC Software, Inc.
 Voice: +1 408 556-0720   1190 Saratoga Avenue, Suite 130
 Fax:   +1 408 556-0735   San Jose, California 95129-3433
 Email: [email-masked]  USA                             
 -------------------------------------------------------------------------

---

From: Bob Clouston <[email-masked]>
Date: Mon, 2 Sep 1996 17:08:52 -0400 (EDT)

I have a few comments to add to Randy and Bob's comments (prefaced by BobC>):

|        Item:      1
|        Page:      -
|        Clause:    -
|        Qualifier: general

BobC>I had been thinking in terms of changes to individual rows,
BobC>and since there are usually only a couple key columns per table to
BobC>worry about, it didn't seem worthwhile.  But a time stamp or
BobC>a sequence number to detect a change to the table is an interesting
BobC>idea.  Can we consider it?  We'd have to be specific for each
BobC>table what constitutes a change.  Counters, for example, would not.
BobC>And some tables might be expected to change so often that its
BobC>not worthwhile.
BobC>By the way, doesn't the text on page 46 describe how to use
BobC>the FRSN to detect changes in the FR tables, or is this just
BobC>not in the right place?

|        Item:      16
|        Page:      12
|        Clause:    5
|        Qualifier: question

BobC> One use is to determine if the agent has restarted, such that
BobC> tables need to be fully collected rather than looking for 
BobC> changes.  A recollection every 497 days won't hurt.  
BobC> Another use is obviously to see how long the node has been up,
BobC> I think 497 days is unlikely, and if it does happen its probably
BobC> fairly obvious if it has wrapped. 

|        Item:      26
|        Page:      17+
|        Clause:    5
|        Qualifier: minor

{
	union	u
	{

	u.elements[0] = 0;
	u.elements[1] = 1;

	elements[0] = 0;
	elements[1] = 1;

BobC> SNA specifies all of these fields are big endian, the MIB should too.

        Item:      43
        Page:      39
        Clause:    5
        Qualifier: question

BobC> I think the sense data fields are the only ones not clear,
BobC> we can word it such that a value of 8 '0's indicate not meaningful.
BobC> The textual convention already says this somewhat.

        Item:      47
        Page:      49
        Clause:    5
        Qualifier: editorial

BobC> There's a window where the time left goes to 0; the node sets
BobC> the garbage collection indicator, and then bumps time left back
BobC> to 1.  Next cycle, the time left goes back to 0, and since the
BobC> indicator is now on, the node is deleted.  "this or the next"
BobC> was stated in case a mib query came during this first window.
BobC> Small window but not impossible.  In fact, in the second case
BobC> the window is also small because the row is quickly deleted.
BobC> So both cases are rare but need to be covered.  We can get more
BobC> a little more wordy about which is which but you can't use the
BobC> indicator to tell because we don't know exactly when it is set
BobC> so there is always a window.  Perhaps something like:
BobC> "A value of 0 represents a case where the node is in the process of 
BobC> being deleted from the database, or is being marked for deletion
BobC> at the next garbage collection cycle."

        Item:      48
        Page:      50
        Clause:    5
        Qualifier: question

BobM> OK; BobM to fix.

BobC> Very similar to above for node time left field.